Cream of the Crop 22

home *** CD-ROM | disk | FTP | other *** search

/ Cream of the Crop 22 / Cream of the Crop 22.iso / comm / iprv094.zip / IPROUTE.TXT < prev next >

Wrap

Text File | 1996-07-31 | 51KB | 1,558 lines

Copyright 1995, 1996 David F. Mischler See the file README.1ST for license information IPRoute PC-based Router V0.94 IPRoute is a software package that routes Internet Protocol (IP) packets between network interfaces on PC hardware. It requires a 286 or better CPU. It is intended to be useful for connecting a LAN to an Internet Service Provider, or for routing between LANs. It provides the following features: * Multiple ethernet interfaces. * SLIP, CSLIP and asynchronous PPP serial links. * Demand-dial and answer scripting. * IP packet filtering. * Network Address Translation (NAT). * Packet and event logging to a syslog daemon. * Routing Information Protocol (RIP). * Multiple transmit queue management strategies. * Administrative preference on routes. * IP tunnelling over ESP using DES-CBC (for US citizens and permanent residents only; not exportable at this time). THIS SOFTWARE IS PROVIDED "AS-IS". THE AUTHOR IS NOT RESPONSIBLE FOR ANY DAMAGES CAUSED BY THE USE OR MISUSE OF THE SOFTWARE, EVEN IF INFORMED OF THE POSSIBILITY OF THESE DAMAGES IN WRITING. THE AUTHOR MAKES NO COMMITMENT REGARDING THE USABILITY OF THE SOFTWARE OR ITS FITNESS FOR A PARTICULAR PURPOSE. SUPPORTED INTERFACES An ethernet interface may be configured by attaching to a packet driver loaded before IPRoute was started with the "packet" command. There is no hard-coded limit on the number of packet drivers allowed, but I have never tested more than two. Packet drivers from the Crynwr Packet Driver Release 11 or later are recommended. At present, only class 1 (ethernet) packet drivers are supported. Only ethernet packet headers are supported (i.e. IEEE 802.3 headers are not supported). Asynchronous serial ports using the standard PC UARTS (i.e. 8250/16450/16550) are supported. These interfaces may be configured with the "async", "slip", "ppp" and "command" commands. The 16550 FIFOs are used to provide far better performance than with the other UARTS. MODEM CONFIGURATION IPRoute can be configured to work with almost any modem, but certain modem settings are expected. Unfortunately, modem configuration commands are not standard enough for me to tell you exactly what commands are needed to configure your modem. IPRoute will generally work best when your modem is set for 8-bit data with no parity and hardware flow control. The data terminal ready (DTR) and carrier detect (CD) control signals should work as "normal" (i.e. a DTR transition from on to off will hang up the phone line, and CD will be on if and only if there is a connection to a remote modem). You may set your modem to return extended result codes if you wish to receive more information on each connection. COMMAND ENTRY All router commands must be entered in lower case. There are several special purpose characters. The backspace or delete characters will erase the last character typed, and the Ctrl-U character will erase the entire line. The enter key must be typed before a command will be executed. When a question mark is entered as a command component the command syntax or options available for the partial command will be displayed (try "route ?" for an example). SCRIPTING IPRoute is normally provided a script file at startup. The script file contains commands to be executed in a particular order under specified conditions. It is possible to specify packet, modem control signal, and timing events. A script processing task is normally run at startup, and additional script processors may be started for each asynchronous interface. This makes it possible for different interfaces to execute scripted commands independently. When a script command requires a string it should be enclosed in double quotes. The backslash character may be used as an escape for various control characters. In particular, \r is used to represent a carriage return, \n represents a line feed, \" represents an embedded double quote, and \\ represents a backslash. It is possible to define symbols for use in scripts with the "define" and "read" commands. The symbols must be preceded by a dollar sign to be expanded. Dollar signs in quoted strings must be preceded by a backslash unless symbol substitution is desired. Whenever a script process transfers control due to an enabled "on" event, all "on" events are disabled. The command reference includes many details about scripting. PACKET FILTERING Packet filtering can be a useful security tool. It is imperative that the network administrator understand how filtering improves security, and that it be used wisely. Most experts on packet filtering recommend that you only allow the packets through your filters that are required to provide the services you need, and drop all others. The best introduction to packet filtering that I know of is Brent Chapman's "Network (In)Security Through IP Packet Filtering", available in PostScript by anonymous FTP from ftp.GreatCircle.COM. The directory path has changed a few times, but the file is still called pkt_filtering.ps.Z. A filtered interface has two separate lists of filtering rules: one for inbound packets, and one for outbound packets. As packets enter or leave the router on a filtered interface they are checked against each filter rule in the order the rules were specified until a match occurs, or the end of the filter list is reached. When a match occurs the actions specified in the filter rule are performed on that packet. Packets that do not match any filter rules will be silently dropped if a filter list exists on the interface for the packet's direction. IP fragments, except for the initial fragment, are not completely filtered because they do not contain port numbers. It is possible for some data to "leak" or be tunnelled past the filter. In general, this is not a serious problem because normal TCP/IP implementations will drop the data if the initial fragments are not received. If you are concerned about packet sniffing or deliberate fragment tunneling then I recommend that you couple NAT with filtering because NAT drops IP fragments whose datagram IDs do not match recently forwarded initial fragments. Please note that a determined user of your internal network might still find a way to tunnel past your filtering scheme. I can not think of any way to make this absolutely impossible. The present implementation drops any initial or only fragment that is too short to contain all of its protocol headers (including the TCP, UDP, or ICMP header), and TCP packets with an IP fragment offset of 1. This prevents certain types of attempts to bypass filtering. Filtering has some performance impact. This impact can be minimized by constructing your filter lists so that, on average, the fewest possible filter rules are checked for each packet. For example, placing a rule that matches all TCP packets that are not connection open attempts (i.e. filter protocol "tcp-xsyn") at the start of the list should improve things a lot. NETWORK ADDRESS TRANSLATION Network Address Translation (NAT) allows a network with non-global addresses to connect to the Internet. This is done by assigning one or more globally valid addresses to the external interface of the router and specifying how addresses and port numbers are to be translated. NAT can be a good security tool for situations where a (potentially) large number of external services are desired by the internal users, but only a few services should be provided to the outside world. In particular, NAT can solve the problem of handling inbound FTP data connections without making all high-numbered TCP ports vulnerable from the outside. This problem has plagued most packet filtering schemes. Two separate tables are maintained for each interface running NAT. One table, the NAT configuration list, is entered as part of the router configuration. It provides a set of rules for setting up new NAT connections. It is always scanned in the order in which the rules were given. The other table is constructed dynamically by the router with one entry for each active translated connection. When a packet representing a new connection comes in on a translated interface it is compared to each entry in the NAT configuration list. A protocol of "*" will match any incoming protocol, but the internal and external IP addresses must be specified. The port numbers must be provided unless neither is given (this indicates that the same port numbers should be used internally as externally). These rules provide enough flexibility for an external address and port to be translated to an internal address and port, or for an external address to be translated to an internal address without port translation. Note that if port numbers are not specified then no service filtering can be performed by NAT. The rules are somewhat different for outgoing connections. When a packet representing a new connection goes out on a translated interface it is compared to each entry in the NAT configuration list. A protocol of "*" will match any outgoing protocol, and an internal address of "*" will match any internal address. Neither port number is usually specified, but it is sometimes necessary to set the external port number to be assigned for use with an internal port number (e.g. outgoing FTP data connections so that the remote system will see the connection originate from port 20 rather than a "random" port). It is also legal (but maybe a little weird) to use "*" for both the internal and external IP addresses, in which case neither the addresses nor port numbers will be translated, but the connection establishment and tracking rules will be enforced. It should be noted that packets that enter the router on a translated interface will have only their destination address and port number translated. Packets that leave the router on a translated interface will have only their source address and port number translated. It is possible to perform "double-blind" translation by enabling NAT on two interfaces, but it is not possible to connect two networks with the same address using this technique. An interface that runs NAT must always have an IP address that is valid on the external network to which it is connected. This is because ICMP error messages may be generated and sent out this interface using the interface's assigned address. If an interface has both filtering and NAT enabled then filtering is always performed first, then translation, except in a few cases where ICMP error messages or TCP resets are generated on the "wrong side" of NAT. This has implications on exactly what can be filtered, logged, and translated. The present implementation drops any initial or only fragment that is too short to contain all of its protocol headers (including the TCP, UDP, or ICMP header), and TCP packets with an IP fragment offset of 1. This prevents certain types of attempts to fool NAT. When NAT is used with PPP with dynamic IP addresses and the NAT external address must correspond to the IP address negotiated by PPP the PPP option "dynamic-nat" should be used. This causes the external IP address of each NAT list entry to be set to the negotiated IP address, all packets with the wrong IP source address to be dropped from the outgoing interface queue, and all dynamic NAT table entries with the wrong external IP address to be deleted. Note that if you are using a dynamically addressed PPP link to route to a fixed IP network then this option must not be used. WHO NEEDS NAT? Several users have told me that IPRoute doesn't work for them unless they enable NAT. Invariably, this is either because they are using unregistered IP addresses, or their Internet Service Provider is not correctly routing packets to their sites for the IP addresses in use. In either case, ordinary routing will not work so NAT is required. PORT NUMBERS, SERVICES, AND PROTOCOLS This information is provided as reference material to assist network administrators. Various network services are discussed with regard to protocol and port numbers. Most of this information comes from the "Assigned Numbers" RFC, which at the time of this writing was RFC 1700. DNS is implemented as both a TCP and UDP service to port 53 on the destination machine. Zone transfers and lists are performed using TCP, so many security experts recommend that machines other than your authoritative secondary DNS servers should be prevented from connecting to TCP port 53 (this could be a job for packet filtering), unless you are controlling zone transfers and listings by some other technique. Client to server communication is generally from arbitrary client ports greater than 1023, but server to server communication generally uses UDP port 53 for both the source and destination. FINGER is implemented as a TCP service to port 79 on the destination machine. In practice, the TCP port on the client machine is 1024 or greater, although this is not a protocol requirement. FTP is the most complicated service in common use. It uses a TCP service to port 21 on the destination machine to provide a control channel, and connects back from the server's TCP port 20 to a port specified by the client machine to provide the data channel. This means that FTP control streams must be monitored by NAT to allow the data connections to succeed. Some servers incorrectly use a source port other than 20. If you need to operate with a server that is broken in this manner then tell NAT about it with the "set nat ftp-data-any on" command. There is also a less common technique ("PASV" mode) that allows the client to connect outward to the server for data connections. If you need to allow incoming passive FTP then you should tell NAT with the "set nat ftp-pasv on" command. HTTP (web service) is implemented as a TCP service to port 80 on the destination machine. The client machine's port is almost always 1024 or greater. NNTP is implemented as a TCP (or UDP?) service to port 119 on the destination machine. In practice, the TCP port on the client machine is 1024 or greater, although this is not a protocol requirement. NTP is implemented as a UDP (or TCP?) service to port 123 on the destination machine. Some client functions use arbitrary ports greater than 1023, but server to server UDP communication uses port 123 on both ends. PING is normally implemented to send ICMP echo requests and receive ICMP echo replies. SMTP (mail) is implemented as a TCP service to port 25 on the destination machine. In practice, the TCP port on the machine sending the mail is 1024 or greater, although this is not a protocol requirement. TELNET is implemented as a TCP service to port 23 on the destination machine. In practice, the TCP port on the client machine is 1024 or greater, although this is not a protocol requirement. TRACEROUTE sends UDP datagrams to the target machine at arbitrary port numbers (usually above 32768), and with the IP TTL field initially set to 1 and increasing for each hop. The destination port number is changed for each hop as well. Each IP router decrements the TTL, and the router that decrements it to 0 sends back an ICMP Time Exceeded (type 11), TTL Exceeded (code 0) message. The target machine should send back an ICMP Destination Unreachable (type 3), Port Unreachable (code 3). Microsoft's TRACERT send ICMP echo requests with a varying time to live rather than UDP messages. LOGGING Events can be logged to a file or a UDP server. Filter entries, as well as various flags, control what is logged. See the "set log" commands for more information. RIP The present RIP implementation is based mostly on RFC 1058. Split horizon is always enabled. RIP requests are not generated or responded to, and no triggered updates are sent. Routes learned by RIP are poisoned for approximately 2 minutes when lost. An administrative preference value may be assigned to routes learned on each interface. See the "rip" command description for more info. TRANSMIT QUEUING All transmit queues are limited. This means that packets will be dropped if the limit is exceeded. In addition, all transmit queues are aged every few seconds if packets are not being transmitted on the interface. During queue aging, the time each packet was queued for output is examined, and any packet whose remaining IP time-to-live (TTL) is less than the time that it has been on the queue is dropped. The TTL of packets that are not dropped is not affected by this process. This behavior is intended to prevent router constipation caused by an interface that fails, or whose modem dropped, etc. If transmit queuing is set to "fifo" then packets are always sent in the order they were queued. In addition, if packets must be dropped due to queue limiting then the first packet on the queue will be dropped. This queuing strategy is especially good for fast interfaces, like ethernet, where the computational overhead of priority queuing would hurt performance, and provide little or no benefit. The optimal tradeoff between link speed and queuing strategy is dependent on the hardware and network characteristics. If transmit queuing is set to "priority" then packets are sent in priority order. The present algorithm uses the IP precedence and type of service to determine a send priority and a save priority. Precedence has a greater effect on these priorities than the type of service. Packets are sent in the order of highest send priority first, and are dropped in the order of lowest save priority first. This queuing strategy is especially good for low-speed SLIP lines, where interactive users will benefit from the improved response time, and high reliability services will benefit from fewer packet drops under congested conditions. Perhaps the biggest weakness of this strategy is that there are still some TCP/IP implementations that do not set the type of service as required by RFC 1122. If transmit queuing is set to "fair" then packets are sent in priority order, but the priority of any packet directly preceded by a newer packet is increased by one. This has the effect of providing better response time than FIFO queuing, but fairer service distribution than strict priority queuing. This queuing strategy is most useful when FIFO queuing provides decent throughput but inadequate response, and priority queuing provides OK response but lousy throughput. It is also less subject to abuse than strict priority routing (e.g. smart users might start doing high-priority file transfers). It has, however, a slightly higher computational overhead than the priority queuing strategy. By default, all async lines use priority queuing, and all ethernet interfaces use FIFO queuing. ADMINISTRATIVE PREFERENCE Each routing table entry includes an administrative preference value. Lower preference values indicate that a route should be preferred over another route with a higher preference value. This can be used to control backup routes, etc. By default, the preference value for all routes is 1. This may be overridden when a static route is created, or by interface for RIP. ENCRYPTED IP TUNNELLING An encrypted IP tunnel can be created with the US-only version of IPRoute using the "tunnel" and "esp" commands. Under current US regulations these functions cannot be exported or provided to persons that are not citizens or permanent residents of the United States. An encrypted security payload (ESP) tunnel allows secure operation of a virtual private network over insecure networks, including the Internet. At the present time only DES-CBC with manual key distribution is supported. Due to the short (56 bit effective) key this encryption technology is not suitable for protecting military secrets or information worth millions of dollars. The security is sufficient, however, to make spoofing very difficult. An ESP tunnel is created by routing packets to the destination network(s) through a tunnel driver, and specifying encryption and decryption keys. Each key has an associated security parameters index (SPI). Outgoing TCP/IP packets routed through the tunnel driver will be encrypted and encapsulated in an ESP/IP packet. Incoming ESP packets will be matched by source IP address and SPI so that the appropriate key can be used to decrypt the encapsulated packet so it may be forwarded. Only true point to point tunnels are supported. Users should be aware that ESP tunnelling has a negative effect on throughput because the resulting packets are larger than the original packets, and are not compressible using any common compression algorithms. COMMAND REFERENCE Warning: all router commands must be in lower case. async <iface> <I/O addr> <IRQ> <speed> [<label>] Configures a standard 8250/16450/16550 serial port for use by the router. Many other commands can make use of the interface after it is configured. Of particular interest are the "command" and "slip" commands, as well as the "send" and "wait" commands for scripting. If a script label is provided then a new script processor will be created that will begin execution at the specified label, and will assume the interface created by this command is meant whenever an interface name is required, but missing. The example below configures the standard PC COM1 port with the name "sl0" and a speed of 9600 bits per second. The interface will be configured in "raw" mode unless a command, such as "slip" changes the encapsulation. async sl0 0x3f8 4 9600 backoff <symbol> <max value> Doubles the numeric value stored in the named symbol, and limits the result to the maximum value specified. This is useful for adjusting redial delays when failures occur. This command will be eliminated if/when general expression evaluation is implemented. command <iface> Starts an interactive command interpreter on the specified interface. At present, only async interfaces are suitable. The example below starts a command interpreter on sl0. command sl0 define <symbol> <string> Only usable in scripts. Defines a script symbol with the supplied double-quoted string as its value. The symbol may then be expanded later in the script by immediately preceding it with a dollar sign. delay <interval> Delays the specified number of seconds before returning. Internal times are maintained in milliseconds, with a resolution of 25 mS. The following example delays for 1.125 seconds. delay 1.125 detach <iface> Intended to disconnects from the hardware and eliminate everything created for an interface. Probably buggy as hell at this time. For now, I recommend you shut down the router and restart it to eliminate an interface. drop filter <iface> Drops all of the packet filter entries previously set up for an interface with the "filter" command. Essentially turns off filtering on an interface. drop nat <iface> Drops all of the network address translation information previously set up for an interface with the "nat" command. Also drops all connection state information. Essentially turns off address translation on an interface. drop packets <iface> Drops all of the outgoing packets queued on an interface. This might be useful for dynamic addressing. drop route <addr/bits> <iface> [<router addr>] [metric <metric>] [preference <pref>] [perm] Drops the route from the routing table that matches the supplied information. esp <iface> {in,out} <spi> des-cbc <key> Associates an SPI and key with a tunnel driver for incoming or outgoing ESP-tunnelled traffic. The <spi> parameter is a 32-bit number. The key is a 64-bit number that must be entered in hexadecimal. exit Logs off an interactive command interpreter. If you use this command on the console you will probably be hitting Ctrl-Alt-Del soon after. filter <iface> [log] [nodial] {deny,drop,permit} {in,out} <proto> <src> <dest> Appends a packet filter rule to the incoming or outgoing list for the specified interface. If the optional "log" qualifier is present, then packets that match the rule will be passed to the logger. The logging commands control exactly what is logged and where it goes. If the optional "nodial" qualifier is present, then packets that match the rule will be silently dropped if the interface is in "raw" mode. This is useful for preventing "noise" packets from establishing a link, but allowing them to be transported if the link is up. One of the action keywords "deny", "drop", or "permit" must be specified. The "deny" action is to drop the matching packet and send an ICMP destination unreachable message back to the packet's originator; the "drop" action is to silently drop the packet, and the "permit" action is to route the packet normally. A direction, "in" or "out", must be specified. These directions are from the router's viewpoint, i.e. "in" refers to packets entering the router from the outside, and "out" refers to packets leaving the router over the filtered interface. The <proto> item is a protocol name or number. The following options are available: * Matches any valid IP packet. esp Matches an ESP packet. icmp Matches any ICMP packet. icmp-du Matches an ICMP destination unreachable. icmp-eq Matches an ICMP echo request (ping). icmp-er Matches an ICMP echo reply (ping response). icmp-pp Matches an ICMP parameter problem message. icmp-rd Matches an ICMP redirect. icmp-sq Matches an ICMP source quench. icmp-tx Matches an ICMP time exceeded. igmp Matches an IGMP packet. ip-ip Matches an encapsulated-IP packet. tcp Matches any TCP packet. tcp-syn Matches TCP with SYN set and ACK clear. This indicates an attempt to open a new connection. tcp-xsyn Matches TCP with SYN clear or ACK set. This indicates a packet for an existing connection. udp Matches any UDP packet. udp-zcs Matches UDP packets with a zero checksum. The <src> and <dest> parameters specify the source and destination IP addresses, masks, and TCP/UDP port numbers. The syntax is [!]a[/w][:{p,p+,pl-ph}], which is just about as confusing as it really is. OK, here goes. The "a" represents an IP address in dotted decimal format, or * to match all addresses. The "/w" is the width of the network mask in bits (e.g. 192.168.0.0/24 would match all addresses whose first 24 bits are 192.168.0). The "!" negates the match on the address and mask only (not on the ports). If a port or port range is specified then it is separated from the address part by a colon. A single port number may be specified, or a port number followed by a plus sign (this represents ports p-65535), or a port range may be specified with two port numbers separated by a hyphen. The following example logs and silently drops attempts to open a telnet connection to any hosts on network 192.168.0.0 that enter the router through interface sl0. filter sl0 log drop in tcp-syn * 192.168.0.0/24:23 goto <label> Only useful in scripts. Causes an immediate and unconditional transfer of control to the specified label. This command disables all "on" events. log <string> Writes the supplied quoted string to the log. This is most useful when there are script symbols in the string. nat <iface> <proto> <int addr:port> <ext addr:port> Appends a network address translation rule to the list for the specified interface. This list is only checked when a packet that does not match an existing connection enters or leaves the router on a translated interface. It is used to control connection establishment. It is scanned linearly when a new connection is required. The <proto> item specifies the protocols that should be allowed to open a new connection. The following values are recognized: "tcp", "udp", "icmp", "igmp", "ip-ip", "esp" or "*" to match any recognized protocol. The <int addr:port> item specifies the internal machine and/or port numbers that should be allowed access. On outgoing connections, both the address and port can be "*" to indicate any internal machine and/or port. On incoming connections the address can only be "*" if the external address is also "*" (this implies that the same addresses must be used inside and out). The port number on incoming connections can likewise only be "*" if the external port number is the same (and this disables port number translation). The <ext addr:port> item specifies the address and/or port numbers that should be used on the externally visible network. The address and port must always be fully specified unless they are the same internally and externally. This is only useful for filtering traffic based on established and approved connection information. This can be useful because it provides a kind of dynamic filtering that classic packet filtering can't do. The following example commands allow for a single external address, 192.0.2.1, and an internal network 192.168.0.0. All outgoing connections from the internal network are permitted, plus SMTP mail from the outside is delivered to 192.168.0.5, and FTP connections from the outside are delivered to 192.168.0.9. All other incoming connections will be dropped. Note that the third line isn't strictly needed. It establishes that outgoing FTP data connections from the internal FTP host will use port 20 externally. This helps keep all sorts of filtering and translating schemes that depend on this behavior happy. nat sl0 tcp 192.168.0.5:25 192.0.2.1:25 nat sl0 tcp 192.168.0.9:21 192.0.2.1:21 nat sl0 tcp 192.168.0.9:20 192.0.2.1:20 nat sl0 * * 192.0.2.1 on cd [<label>] Only useful in scripts. Specifies that when CD becomes active on an interface during a "wait" command the script should resume execution at the specified label. Leaving off the label cancels any established label. on cdloss [<label>] Only useful in scripts. Specifies that when CD becomes inactive on an interface during a "wait" command the script should resume execution at the specified label. Leaving off the label cancels any established label. on packet [<label>] Only useful in scripts. Specifies that when a packet is queued on an interface during a "wait" command the script should resume execution at the specified label. Leaving off the label cancels any established label. A special form of this command exists, "on packet *", to go to the script label associated with the routing table entry for the packet's destination address. on ring [<label>] Only useful in scripts. Specifies that when RI becomes active on an interface during a "wait" command the script should resume execution at the specified label. Leaving off the label cancels any established label. on timeout [<label>] Only useful in scripts. Specifies that when a timeout occurs during a "wait" or "slip" command the script should resume execution at the specified label. Leaving off the label cancels any established label. packet <iface> <int #> <addr/bits> [broadcast <brdcst addr>] [mtu <mtu>] Configures a device interfaced by a packet driver for use by the router. At present, only ethernet (class 1) packet drivers are supported. The example below configures a packet driver using the standard software interrupt 0x60, and indicates that the interface IP address is 192.168.1.254, and the network mask is 255.255.255.0. By default the MTU is set to 1500 and 255.255.255.255 is used as the broadcast address. packet en0 0x60 192.168.1.254/24 ping <addr> Sends 5 ICMP echo requests to the specified address and displays any replies received. ppp <iface> <timeout> <addr/bits> [broadcast <brdcst addr>] [mtu <mtu>] [dynamic-nat] Starts PPP on the specified interface. The interface will revert to "raw" mode if no packets are received for <timeout> seconds, or if a carrier drop is detected, or if the peer requests LCP link termination. The IP address and mask are treated like the ones in the "packet" command, except that a "*" is used to indicate dynamic IP address assignment. If the "dynamic-nat" option is used then when the local IP address is negotiated all entries in the NAT list will be modified to use the negotiated address externally, any active NAT connections with a different external address will be removed, and any outgoing queued packets with the wrong source IP address will be dropped. If this command is typed in to a command interpreter then a new process will be started to execute the command. If this command is part of a script then script execution will pause until the interface reverts to raw mode. If this was due to a timeout or carrier drop then any enabled "on" event for these conditions will be taken. read <iface> <timeout> <terminator string> <symbol> Only usable in a script. Reads a string ending with one of the specified terminator characters into the specified symbol. The symbol may then be expanded later in the script by immediately preceding it with a dollar sign. This is intended for purposes like reading an IP address from a SLIP server. rip <iface> [default] [preference <pref>] [quiet] [{v1,v2,off}] Turns on/off RIP broadcasts on the specified interface. By default, the entire routing table will be sent in version 1 responses. The "v2" qualifier causes RIP version 2 responses to be sent, but still broadcasts rather than multicasts. The "default" qualifier causes only a default route to be broadcast rather than the real routing table. The "preference" option specifies the administrative preference to be assigned to routes learned via RIP on this interface. The "quiet" qualifier causes routes to be learned but not distributed on this interface. route <addr/bits> <iface> [<router addr>] [metric <metric>] [preference <pref>] [perm] [label <label>] Adds a static route to the routing table. The "perm" qualifier is required if packets are to be routed to an interface that is not encapsulating IP (e.g. an async interface running a script that will dial and establish a SLIP link when packets are queued to the interface). The "label" parameter is for use with the "on packet *" command. send <iface> <string> Sends the quoted string out the specified interface. set echo {off,on} Controls character echo while matching strings in a "wait" command. set filter deny-code <ICMP DU code> Sets the code carried in the ICMP destination unreachable messages sent by the router when a packet matches a filter rule whose action is "deny". By default, the code is set to 1 (host unreachable). RFC 1812 says the value should really be 13, but many hosts seem to ignore this code. The default will probably change in a future release. set interface <iface> cd {ignore,normal} Controls the use of CD on an interface. By default, CD is used to detect modem disconnects. The state of CD can be ignored with the "ignore" qualifier. set interface <iface> dtr {off,on} Controls the state of DTR on an interface. By default, DTR is low at the EIA interface. This signal is used to control modem answer and hangup. set interface <iface> mtu <mtu> Sets the MTU on the specified interface. set interface <iface> queue fair Sets the transmit queue for the specified interface to queue (and drop) packets using a modified priority algorithm with improved fairness. set interface <iface> queue fifo Sets the transmit queue for the specified interface to queue (and drop) packets in a FIFO manner. set interface <iface> queue limit <limit> Sets the outgoing queue packet limit for the specified interface. set interface <iface> queue priority Sets the transmit queue for the specified interface to queue (and drop) packets in a prioritized manner. set interface <iface> rts {flow,off,on} Controls the interface RTS line. The "flow" qualifier establishes RTS/CTS flow control. set interface <iface> speed <bps> Controls the interface speed. set log brief Reduces the data logged for each packet to 1 or 2 lines. This is the default. set log data Expands the data logged for each packet to the entire packet contents. set log errors {off,on} Controls whether the router logs various errors. The default is "on". set log file <filename> Specifies a file for the log data to be written to. "CON" specifies logging should be to the console display. set log headers Expands the data logged for each packet to the IP and TCP/UDP/ICMP headers. set log memory <lines> Specifies how many lines of the log are queued in memory. The default is 240. Values over 2000 are not recommended. set log monitor {off,on} Enables console display of all messages written to the log. set log none Disables logging to a file or UDP server. set log raw {off,on} Controls logging of raw device input received while executing "wait" commands. This is especially useful for debugging dial/login scripts. The default is off. This command only works in a script interpreter that is attached to the interface you want to log. set log timestamp {off,on} Controls time stamping of log entries. This should not be used if you are logging over the network and timestamping can be performed by the logging host because no attempt is made to synchronize the DOS clock with an outside source. This feature is off by default. set log udp <ip addr[:port]> Specifies that log entries should be sent to the UDP server at the specified IP address and port. The format is suitable for use with the BSD syslog daemon. If no port is specified then port 514 (syslog) is assumed. set nat ftp-data-any {off,on} Specifies whether NAT will permit remote FTP servers to make incoming data connections to the client with a source port other than 20. The default is off. WARNING: This will allow arbitrary TCP connections into your network with the internal endpoint specified by the FTP control stream. This is probably safe, but it might make your network less secure to enable this feature. set nat ftp-pasv {off,on} Specifies whether NAT will process incoming passive mode FTP connections correctly. The default is off. WARNING: This will allow arbitrary TCP connections into your network with the internal endpoint specified by the FTP control stream. This is probably safe, but it might make your network less secure to enable this feature. set nat pass-icmp-errors {off,on} Specifies whether NAT will translate ICMP errors for open connections. The default is on. set nat ports <lowest port> <highest port> Specifies the range of port numbers used externally by NAT. The default is 1024 through 4999. set nat send-icmp {off,on} Specifies whether NAT will attempt to cause bad/old connections to drop by sending ICMP messages. This feature causes the router to spoof the IP address of the intended destination of the original packet. The network administrator must beware, because things are not quite as they seem. This feature is off by default. set nat send-reset {off,on} Specifies whether NAT will attempt to cause bad/old connections to drop by sending TCP reset messages. This feature causes the router to spoof the IP address of the intended destination of the original packet. The network administrator must beware, because things are not quite as they seem. This feature is off by default. set ppp <iface> authenticate {off,chap,pap} Specifies the authentication protocol that the remote peer will be required to use for authentication. The only CHAP algorithm available is the IETF standard CHAP based on MD5. This feature is off by default. set ppp <iface> login <name> <password> Specifies the name and password to use for authentication as a client. set ppp <iface> peerip <IP address> Specifies the IP address that will be assigned to the remote peer during IPCP negotiation. If you do not set this option then any address will be accepted. set ppp <iface> trace {off,on} Controls the logging of PPP trace information for the specified interface. When enabled, the PPP negotiation information will be logged. This is helpful when analyzing PPP problems. set ppp <iface> vjtcp {off,on} Controls the negotiation of Van Jacobson TCP/IP header compression. When turned off, this feature disables VJTCP in both directions. This feature is on by default. set trace {off,on} Controls logging of script commands. This is very useful for debugging all sorts of scripts. The default is off. show arp Displays the ARP table. show filter <iface> Shows the filter list and match counts for an interface. show interface [<iface>] Shows various interface parameters and counters. show nat <iface> [status] [debug] Shows the static NAT list, or the dynamic connection table with the "status" parameter. show options Displays various compile-time options, and the values of some settable features that cannot be viewed elsewhere. show route Displays the routing table. show task Displays the active task list. show version Displays the version identification message. shutdown Shuts down the router software. slip <iface> <timeout> <addr/bits> [broadcast <brdcst addr>] [mtu <mtu>] [compress] [allow-compress] Starts SLIP on the specified interface. The interface will revert to "raw" mode if no packets are received for <timeout> seconds, or if a carrier drop is detected. The IP address and mask are treated like the ones in the "packet" command. The default SLIP MTU is 1006 bytes (as per RFC 1055). If the optional "compress" keyword is specified then Van Jacobson TCP header compression will be performed. If "allow-compress" is specified then Van Jacobson TCP header compression will be enabled only if it is detected from the remote end of the link. If this command is typed in to a command interpreter then a new process will be started to execute the command. If this command is part of a script then script execution will pause until the interface reverts to raw mode. If this was due to a timeout or carrier drop then any enabled "on" event for these conditions will be taken. tip <iface> Connects to a "raw" interface. Sometimes useful for configuring modems and stuff. Type ^] to exit. This will not work as expected if a script is running. tunnel <iface> <addr/bits> esp <remote addr> [mtu <mtu>] Creates a tunnel driver that uses the specified address and prefix width as its tunnel endpoint, and that tunnels to the specified remote IP address. At this time only ESP tunnelling is supported. user <username> <password> <addr/bits> Creates a user entry for inbound authentication with CHAP or PAP. The IP address and prefix width are not used at this time. wait <iface> <timeout> [exact] [<string>] Waits for the timeout to expire, or the string to be matched, or an enabled "on" event to occur. EXAMPLE ROUTER CONFIGURATION USING SLIP ; ; IPR script for example configuration. ; ; Configure ethernet interface on network 192.168.0.0/24 packet en0 0x60 192.168.0.254/24 ; Configure my modem port and make it the default route async sl0 0x3f8 4 57600 do_sl0 route * sl0 perm ; Broadcast RIP routes on the ethernet rip en0 ; Start a command interpreter on the console command exit ; ; Script for filter and NAT configuration on sl0, ; with demand dial out, etc. ; do_sl0: set trace on ; ; Set up packet filtering. ; ; Allow established TCP filter permit in tcp-xsyn !192.168.0.0/22 38.145.214.209 ; Drop and log attempts to spoof internal addresses, or our external address filter log drop in * 192.168.0.0/22 * filter log drop in * 38.145.214.209 * ; Allow UDP responses. NAT will keep out unsolicited packets. filter permit in udp * 38.145.214.209 ; Allow incoming mail and FTP connections filter permit in tcp-syn * 38.145.214.209:25 filter permit in tcp-syn * 38.145.214.209:21 filter permit in tcp-syn *:20 38.145.214.209 ; Allow DNS zone transfers from 192.33.4.10 filter permit in tcp-syn 192.33.4.10 38.145.214.209:53 ; Drop and log everything else. filter log drop in * * * ; ; Set up NAT ; ; Allow SMTP mail to come in. nat tcp 192.168.0.69:25 38.145.214.209:25 ; Allow FTP requests to be serviced. nat tcp 192.168.0.69:21 38.145.214.209:21 nat tcp 192.168.0.69:20 38.145.214.209:20 ; Allow DNS zone transfers (packet filtering controls with whom). nat tcp 192.168.0.69:53 38.145.214.209:53 ; Allow all outgoing service requests and their responses. nat * * 38.145.214.209 ; ; Configure modem control and set up for demand dial. ; set interface rts flow hangup: set interface dtr off delay .5 set interface dtr on on packet dialout wait 0 ; ; Dial the phone, log in, and run SLIP. ; Hang up if no packets are received for 10 minutes. ; dialout: send "ATDT 555-1212\r" wait 1 on timeout hangup wait 45 "CONNECT" ; Read the rest of the CONNECT message into symbol "speed". on cd lineup read 5 "\r" speed wait 60 lineup: on cdloss hangup on timeout hangup send "\r\r" wait 5 "Username: " send "IWantToBeA\r" wait 5 "Password: " send "Schutzhund3\r" wait 5 "Local> " send "CONNECT SLIP\r" log "Connected at $speed" slip 600 38.145.214.209/24 mtu 1006 EXAMPLE ROUTER CONFIGURATION USING PPP (STATIC) ; ; IPR script for example configuration with PPP ; using a static IP address. ; ; Configure ethernet interface on network 192.168.0.0/24 packet en0 0x60 192.168.0.254/24 ; Configure my modem port and make it the default route async sl0 0x3f8 4 57600 do_sl0 route * sl0 perm ; Broadcast RIP routes on the ethernet rip en0 ; Start a command interpreter on the console command exit ; ; Script for filter and NAT configuration on sl0, ; with demand dial out, etc. ; do_sl0: set trace on ; ; Set up packet filtering. ; ; Allow established TCP filter permit in tcp-xsyn !192.168.0.0/22 38.145.214.209 ; Drop and log attempts to spoof internal addresses, or our external address filter log drop in * 192.168.0.0/22 * filter log drop in * 38.145.214.209 * ; Allow UDP responses. NAT will keep out unsolicited packets. filter permit in udp * 38.145.214.209 ; Allow incoming mail and FTP connections filter permit in tcp-syn * 38.145.214.209:25 filter permit in tcp-syn * 38.145.214.209:21 filter permit in tcp-syn *:20 38.145.214.209 ; Allow DNS zone transfers from 192.33.4.10 filter permit in tcp-syn 192.33.4.10 38.145.214.209:53 ; Drop and log everything else. filter log drop in * * * ; ; Set up NAT ; ; Allow SMTP mail to come in. nat tcp 192.168.0.69:25 38.145.214.209:25 ; Allow FTP requests to be serviced. nat tcp 192.168.0.69:21 38.145.214.209:21 nat tcp 192.168.0.69:20 38.145.214.209:20 ; Allow DNS zone transfers (packet filtering controls with whom). nat tcp 192.168.0.69:53 38.145.214.209:53 ; Allow all outgoing service requests and their responses. nat * * 38.145.214.209 ; ; Configure modem control and set up for demand dial. ; set interface rts flow hangup: set interface dtr off delay .5 set interface dtr on on packet dialout wait 0 ; ; Dial the phone, log in, and run PPP. ; Hang up if no packets are received for 10 minutes. ; dialout: send "ATDT 555-1212\r" wait 1 on timeout hangup wait 45 "CONNECT" ; Read the rest of the CONNECT message into symbol "speed". on cd lineup read 5 "\r" speed wait 60 lineup: on cdloss hangup on timeout hangup log "Connected at $speed" set ppp login mischler xerxes ppp 600 38.145.214.209/24 goto hangup EXAMPLE ROUTER CONFIGURATION USING PPP (DYNAMIC) ; ; IPR script for example configuration with PPP ; using a dynamically negotiated IP address. ; ; Configure ethernet interface on network 192.168.0.0/24 packet en0 0x60 192.168.0.254/24 ; Configure my modem port and make it the default route async sl0 0x3f8 4 57600 do_sl0 route * sl0 perm ; Broadcast RIP routes on the ethernet rip en0 ; Start a command interpreter on the console command exit ; ; Script for filter and NAT configuration on sl0, ; with demand dial out, etc. ; do_sl0: set trace on ; ; Set up NAT ; ; Allow all outgoing service requests and their responses. ; The IP address is not critical, but should be the most ; likely address (or at least a possible address). nat * * 38.145.214.209 ; ; Configure modem control and set up for demand dial. ; set interface rts flow hangup: set interface dtr off delay .5 set interface dtr on on packet dialout wait 0 ; ; Dial the phone, log in, and run PPP. ; Hang up if no packets are received for 10 minutes. ; dialout: send "ATDT 555-1212\r" wait 1 on timeout hangup wait 45 "CONNECT" ; Read the rest of the CONNECT message into symbol "speed". on cd lineup read 5 "\r" speed wait 60 lineup: on cdloss hangup on timeout hangup log "Connected at $speed" set ppp login mischler xerxes ppp 600 * dynamic-nat goto hangup EXAMPLE AUTOEXEC.BAT rem Load packet driver and start IPR. smc_wd 0x60 10 0x280 0xd000 ipr script.ipr